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TITLE 



SYSTEM FOR CAPTURING TRADE INFORMATION 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates to an automated 
trade capture system having a client interface. 
Related Background Art 

Various automated systems already exist for 
1 executing trades among brokers, market managers, 

individual traders and other financial entities. See, 
for example, U.S. Patents Nos . 4,674,044, 5,950,176, 
and 5,963,923. In addition, a few large brokerages 
have developed on-line trading systems for individual 
15 traders. These systems, however, do not provide for 

middle office and back office processing, such as by an 
investment bank acting either as a principal or a 
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clearing agent, of a trade previously executed between 
two parties . 

Such middle and back office processing has 
been performed internally by the investment bank of 
5 Lehman Brothers, in an in-house version of its 

S MARTT I C KE T™ automated trade capture system. In this 
system, executed trade information was captured by 
Lehman Brothers personnel from written documents sent 
to them from external clients. The captured trade 

10 information was then sent through a workflow process 
consisting of trader and middle office trade 
authorizations, as well as back office processing. 

However, while being automated, this in-house 
system did not permit any trade capture to be performed 

15 by the clients themselves. Further, the trades were 
mostly limited to derivatives . 

A client-assessable trade capture system is 
desirable, however, because it would provide clients 
with a single trade capture platform, in which products 

20 besides derivatives, such as cash and futures trades, 
may be handled, which in turn provides the investment 
house a competitive advantage. A client-assessable 
trade capture system would also provide the clients 
with links to the internal risk, margin and 
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counterparty services of the investment bank, access to 
historical trade activity, as well as trade validation 
and confirmation. 

5 SUMMARY OF THE INVENTION 

To overcome the above-described and other 
limitations in the art, the present invention relates 
to a system that preferably provides an efficient and 
streamlined system for capturing trades that can be 

10 operated by the client at its site. 

In one aspect of the present invention, a 
trade capture system is provided that includes a first 
computer having an interface for capturing executed 
trade data, a second computer for accepting the 

15 captured trade data and performing middle and back 
office processing on the same, and a communication 
channel for communicating the captured trade data 
between the first and second computers. Preferably, 
the first computer is a client computer, the second 

20 computer is an investment bank computer, and the 

communication channel is the Internet, wherein the 
client computer's interface is a browser. 

In another aspect of the present invention, a 
trade capture system is provided which includes a first 



computer having an interface for transmitting 
electronic trade tickets, a second computer for 
receiving the electronic trade tickets and performing 
middle and back office processing on the same, and a 
5 communication channel for communicating the electronic 
trade tickets between the first and second computers. 

These and other aspects of the present 
invention are described in more detail below. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a state diagram showing the states 
and actions ("workflow") of the present invention. 

Fig. 2 is a screen shot of a graphical user 
interface of the present invention relating to a new 
15 deal. 

Fig. 3 is a screen shot of a graphical user 
interface of the present invention relating to a swap 
accelerator. 

Fig. 4 is a screen shot of a graphical user 
20 interface of the present invention relating to a 
generic swap. 

Fig. 5 is a screen shot of a graphical user 
interface of the present invention relating to a swap 
leg of Party A. 
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Fig. 6 is a screen shot of a graphical user 
interface of the present invention relating to a swap 
leg of Party B. 

Fig. 7 is a screen shot of a graphical user 
5 interface of the present invention relating to a trade 
authorization. 

Fig. 8 is a screen shot of a graphical user 
interface of the present invention relating to risk 
management details. 
10 Fig. 9 is a screen shot of a graphical user 

interface of the present invention relating to a deal 
filter. 

Fig. 10 is a screen shot of a graphical user 
interface of the present invention relating to a deal 
15 workflow history. 

Fig. 11 is a block diagram of the system 
architecture of the present invention. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
20 OVERVIEW 

The following describes as a preferred 
embodiment of the present invention Lehman Brothers ' 
SMARTTICKET™ client-based trade capture system that was 
first made publicly available on January 17 , 2000. 



However, the following description is not limited to 
that system, and may include additional features not 
present in that system. 

An embodiment of the present invention is 
5 shown in Fig. 11, and includes a client computer 1100, 
a communication channel 1102, and the investment bank's 
middle office and back office processing computer 
system 1104. As shown in that figure, the client 
computer 1100 of the present invention is installed at 

10 the client's site, and is preferably connected to the 
investment back's computer system 1104 through the 
Internet 1106. Of course, other types of well-known 
communication channels 1102 may be employed instead to 
connect and communicate information between the client 

15 computer 1100 and the investment bank's computer system 
1104. 

Executed trades may be entered directly into 
the system's interface 1110 on the client's computer. 
Alternatively, the client may have its own interface 
20 1112 which connects to the system of the present 

invention, and in that case, the trades are entered by 
the client into its own interface, which in turn are 
transmitted through the Internet or other communication 
channel to the system 1104. 



Additionally, the system 1104 may receive 
from the client's computer 1100, via the electronic 
trade ticket interface 1114, over the Internet or 
communication channel, trade tickets which contain the 
5 executed trade data. This eliminates, or at least 

reduces, the need for the client to key trade data into 
its interface. The investment back system 1104 accepts 
those trade tickets electronically, preferably using 
XML technology, on a real-time basis. 

10 Because it is desirable for the system 1104 

to support as many clients as possible, it supports a 
wide variety of trades besides traditional derivatives. 
Accordingly, the system 1104 is described below with 
respect to trades, such as swaps, swaptions, caps, 

15 floors, FX, and cash, related to derivatives, futures 
and cash products, including both U.S. and non-U. S. 
products. However, it will be appreciated that the 
system may be extended to accept executed trades of 
other financial products. As will be described in more 

20 detail below, to give clients more flexibility to trade 
in both derivatives and cash products, templates exits 
for both the derivatives and cash business. For 
example, these templates allow for the capture of 
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outright bond trades, financing trades and futures and 
options trades. 

Separate entities within the investment bank 
system 1104 are set up according to product type, 
5 mainly for security and safekeeping purposes. For 

example, for U.S. products and for global derviatives, 
separate entities are set up for each client in the 
respective internal system. For non-U. S. cash 
products, a separate entity is also used to segregate 

10 the client's financing trades to properly keep them 
(i.e., for client reporting and balance sheet 
purposes). In addition, for U.S. cash products, a 
unique bank depository may be set up for each client, 
while for non-U. S. cash products, a investment bank or 

15 bank/depository account may be used. Separating each 
client's data provides a security layer to the system, 
because a client can view and access only its own 
trades and no others. Further, a profile may be set up 
for each client, in which the client is restricted to 

20 access only certain products (e.g., swaps), allowing 

the client to trade in only those products for which it 
signed up for. 

In addition, to support hedge funds clients, 
the client's interface 1104 supports a client 



allocation function. This function allows the client 
to enter a single trade and then allocate that trade 
into multiple trades (i.e., multiple funds) based on 
the allocation breakdown specified by the client. This 
5 function significantly speeds up the trade capture 
process for those clients. 

Further, the client's interface may includes 
a trade blotter screen developed for that client's 
business. This blotter gives the client the ability to 

10 sell of its trades, across different product types, on 
one integrated screen. Data may be viewed for the 
current day of any date range entered. 

Once the trade data have been captured by the 
system 1104, the trade data may be routed to the 

15 appropriate internal system of the investment house, 
based on the product. The investment bank may then 
verbally confirm, on trade date, the trade that the 
client has executed with its street counter-party. 
This trade may be confirmed with the investment bank 

2 0 acting as either a principal or as a clearing agent. 
Once the trades are confirmed, they may be settled by 
the investment bank, for which the investment bank 
moves either the cash or securities based on the 
client's instructions. The client may then be notified 
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of the trade settlement by the investment bank, for 
example, by its computer system, through the 
communication channel, to the client's computer. 

5 DEAL CAPTURE 

This section describes a preferred embodiment of 
capturing deal information in the system of the present 
invention- Deal capture begins with specification of 
the product type to be captured. This allows the 

10 system to provide the user with a template for 

capturing the specific information needed for that 
deal. Field entry is simplified, because values for as 
many fields as possible are defaulted based on product 
type. As fields are populated, other fields are 

15 assigned default values based on that information. 
Field entry may then be validated for all fields. 
Files may then be saved and named in preparation of 
moving deals into the system workflow, which is also 
described in detail below. 

20 System menus and toolbars may be configured 

similar to Microsoft applications, with all functions 
available on drop-down menus at the top of the screen. 
Selected functions are available as buttons on the 
system toolbar. The user preferably has access to all 
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functions through both mouse and keystroke selection. 
If any function cannot logically be performed by a user 
based on the user profile, deal state, or mode of file 
access, that menu item is made inactive. Inactive menu 
5 items are stippled (shaded light gray). 

As shown in Fig. 2, new deals are created by 
first selecting a senior product type and a subordinate 
product type, which together define the structure and 
data fields needed to capture that deal. 
10 For example: 

Senior Product Type = Interest Rate Swap 
Subordinate Product Type = Generic Fixed vs. 

Floating 

A template may then be stored in system for 
15 each combination of senior and subordinate product 
types. As new deal structures are recognized, new 
product types may be defined, and new templates may be 
created by system users. In addition to the system 
templates created for all users, each user will be able 
20 to create custom (or "user") templates for individual 
or shared use. The user will be able to choose from 
the lists of system and custom templates to initiate 
deal capture. The client's interface preferably only 
contains the system templates . Figs . 3 and 4 
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respectively show a swap accelerator and a generic swap 
generated by the client using the templates. 

When the first piece of deal information is 
captured, the selected template becomes a "Deal in 
5 Progress", which is the first valid deal state (102) in 
the system workflow. The Deal in Progress is assigned 
an ID within system that remains with the Deal in 
Progress until it becomes an authorized deal, or is 
deleted. The Deal in Progress belongs exclusively to 

10 the user creating it until it is explicitly shared with 
other users, called a Deal in Progress Transfer. The 
ticket will remain in the user inbox of the creator 
until it is sent to another user for processing. 

In the system of the present invention, Party 

15 A may be selected to be the investment bank entity. 

The defaulting investment bank entity is based on user 
preferences and can be changed based on a choice list 
of valid investment bank entities. As for the 
counterparty (Party B), a counterparty browser allows 

20 the selection of that party directly from an entity 
master database. This ensures that deals are booked 
with valid counterparties . In addition to counterparty 
name, branch, and ID, other information about the 
counterparty stored on the entity master database are 
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viewable. Preferably, none of the information in the 
entity master database is editable from the system of 
the present invention itself, and thus is separately 
edited. In cases where the counterparty has not yet 
5 been set up on the entity master database, the option 
to enter the counterparty as " TBD " (To Be Determined) 
with a free-format name is provided. Replacement of 
the "TBD" counterparty with a counterparty from the 
entity master database may be enforced by preventing 

10 the deal from reaching its final state until the "TBD" 
counterparty issue is resolved. 

System field entry consists of populating the 
selected template with deal information. In most 
cases, fields will have a default value based on the 

15 product type, or the values of other fields. The user 
may override these defaults, however, usually by 
picking from a choice list of values. 

Field values are typically validated 
according to validation rules recorded in the system. 

20 If a field value is determined to be invalid, an error 
message is displayed and the focus will remain on that 
field. Where applicable, fields may be validated in the 
context of the values of other fields on the ticket. 
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The system also includes a field propagation 
engine, which is used to propagate the effects of one 
changed field value on other fields. A change in one 
field may propagate such changes to other fields such 
5 as making them visible or invisible, changing their 
default values, and determining whether they are 
required or not required. 

Required fields are those fields that must be 
populated given the selected product type, the values 
10 of other fields that have already been populated, and 
the state of the deal (which states are described in 
detail below) . If a field is required given these 
parameters, the system does not allow the deal to 
transition to the next state. There are no fields 
15 required for a ticket to exist in the Deal in Progress 
state. All economic data fields are preferably 
required before trader authorization can occur. 

A limited free-format comment field is 
provided on each template to capture information that 
2 0 cannot be captured on an existing template. This 

comment field is monitored by the middle office so that 
an appropriate custom template can be constructed. 

System deal legs may be selected, copied, and 
pasted within deals or from one deal to another. The 
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deal the leg is being copied from may be open in Write 
Mode or Read-only Mode, but the deal the leg is being 
pasted onto must typically be open in Write Mode. If a 
deal is open in Write Mode, legs may be selected and 
5 deleted. Legs may also be chosen from a menu of 

available legs to be inserted onto a deal. A display 
of swap legs is shown in Figs . 5 and 6 . 

During deal capture, the system periodically 
saves captured deal information to a temporary file to 

10 minimize data loss due to an interruption in network 
service or an unanticipated PC re-boot. The temporary 
save occurs every pre-determined number of minutes 
(e.g., five minutes), and the temporary file is deleted 
when the user explicitly closes the file, which is 

15 known as a "clean close". When logging on to the 

system, the user is advised of any files that were not 
"closed clean" when the user last logged out. The user 
may then be given the option to recover the last 
autosaved version of the file. 

20 A file may be saved as a Deal in Progress or 

as a custom template. If a deal in progress has not 
previously been explicitly saved, the user may be 
prompted to save the file as a Deal in Progress or as a 
custom template. If the file has been previously 
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saved, or if the file is an authorized deal, the 
updated version of the file may be saved in place of 
the old version. Any file may be saved as a Deal in 
Progress. None of the fields on a system or custom 
5 template are required for a file to be saved as a Deal 
in Progress. Any file open in Write Mode or Read-only 
Mode may be saved as a custom template. The resulting 
custom template will be "owned" by the user who created 
it, and will be available only to that user unless 

10 explicitly changed by that user. 

Preferably, system file names consist of the 
originating office, the trade date, the Party A ID, the 
Party B ID, and a user-defined free-format portion. 
This free-format portion is created by the user who 

15 originates the deal, and may be changed only by that 
user unless "ownership" of that deal is explicitly 
changed. 

SYSTEM WORKFLOW 
20 This section describes a preferred embodiment 

of the workflow of the system of the present invention. 
System workflow entails moving a ticket through a 
series of states, each closely associated with a group 
of users that must process the ticket in each state. 
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There are five valid deal states: Deal in Progress 102,. 
(Deal) Pending Trader Authorization 104, (Deal) Pending 
AAA Authorization (105), (Deal) Pending Middle Office 
Processing (106), and Active Deals in Back Office 
5 (107). In the basic workflow, a Deal in Progress is 
created by the client or by a marketer, who populates 
most of the deal information fields and obtains the 
necessary credit and AAA approvals (AAA approvals are 
simply an extra level of authorization required for 

10 certain deals by the investment bank). The Deal in 
Progress of state 102 is then submitted for trader 
authorization, entering the Pending Trader 
Authorization state 104. When authorized, the deal 
then moves to the Pending Middle Office Processing 

15 state 106. When this is complete, the ticket is 

authorized to the final state, Active Deals in Back 
Office 107. If the deal is an AAA trade, it must pass 
through the additional state 105 of Pending AAA 
Authorization before reaching the Pending Middle Office 

20 Processing state 106. At any time after the ticket 
becomes an authorized deal, users will be able to 
Attach Proposed Edits to the ticket and re-submit it 
for Trader Authorization. The system workflow also 
handles processing of terminations and assignments. 
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Fig. 1 is a state diagram showing the states 
and actions of the system workflow. Each large circle 
represents one state that the executed trade, or 
"deal", may take while being processed by the system. 
5 The thick, dark arrows represent successful movements 
in which the deal goes forward. The dotted lines 
represent deal deletions or rejections, or a rejection 
by the trader of a proposal from the middle office or 
back office. The dashed lines represent proposals from 
10 the middle office or back office. 

In state 101 "Deal Being Created But Not 
Saved Yet", the client enters into the graphical user 
interface of the system the required trade information, 
as well as other deal-related information, as explained 
15 further below. When all necessary information has been 
entered, the client saves the deal, which brings the 
workflow to state 102, "Deal in Progress". 

In state 102, two actions may occur: the 
client may delete the deal in progress, in which case 
20 the workflow moves to state 103, "Deal No Longer 

Exists". At that point, the deal dies and no further 
action is taken. 

Alternatively, the deal is submitted to the 
trader for authorization, in which case the workflow 
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moves to state 104, "Pending Trader Authorization". In 
this state, the trader may authorize or reject the 
deal. If the deal is rejected, the workflow returns to 
state 102, at which point the client may update the 
5 deal in progress and resubmit for authorization, or may 
delete the deal. 

As stated above, in state 104, the deal may 
be authorized by the trader, in which case the workflow 
moves to state 106, "Pending Middle Office Processing". 

10 In certain cases, which are explained in further detail 
below, the deals must be additionally authorized by AAA 
and before being sent to the middle office for 
processing. In this case, the deal is sent to state 
105, "Pending AAA authorization". Upon AAA 

15 authorization, the workflow moves to state 106 for 
middle office processing. Otherwise, if AAA rejects 
the deal, the workflow returns to state 104, at which 
point the deal may be updated or rejected back to the 
client. 

20 In state 106, the middle office may authorize 

the deal, and depending upon the deal action type, 
either sends it to the back office, in which case the 
workflow moves to state 107 "Active Deals in Back 
Office", or to the inactive deals, in which case the 
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workflow moves to state 108 "Inactive Deals". Upon 
deal authorization, the client is notified of the same. 

Alternatively, the middle office may reject 
the deal back to the trader, in which case the workflow 
5 returns to state 104, or to the AAA authorizer, in 
which case the workflow returns to state 105. In the 
former case, the trader may update the deal and 
resubmit it to the middle office (to state 106), or may 
instead send the rejected deal back to the client (to 

10 state 102). In the latter case, the AAA authorizer can 
update the deal and resubmit it to the middle office 
(to state 106), or may instead send the rejected deal 
back to the trader (to state 104), which is handled by 
the trader as described above. 

15 In addition, the middle office may propose 

that the deal be canceled, in which case the workflow 
returns to state 104. The trader may then cancel the 
deal and notify the client, or may reject the proposed 
cancellation, in which case the workflow returns to 

20 state 106. 

Deals are characterized by an action type 
(listed with its associated abbreviation), including 
but not limited to: 

New deals: ND; 



Change (aka Correct/Edit ) : CH; 

Termination - Full: FT; 

Termination - Partial: PT; 

Assignment - Full Only: FA; 
5 Cancellation: CA; 

Option Exercise: CX; or 

Option Expiry: OX. 
Further, deal in progress may be saved or deleted, new 
deals may be rejected, deals may mature, and proposals 
10 may be rejected. 

If the deal action is a full termination, a 
cancellation, and option exercise or an option expiry, 
all of which represent of inactive deals, the middle 
office authorizes the deal to be sent to state 108. 
15 Otherwise, if the deal is a new or corrected deal, or 
involves a partial termination or an assignment, all of 
which represent active deals, the deal is sent to the 
back office for further processing (in accordance with 
the required action), state 107. In addition, the deal 
20 may mature via the payment system of the back office, 
in which case it becomes inactive and the workflow 
moves to state 108. 

The back office may make certain proposals to 
the deal to the trader, as follows: changes (edits); 
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full terminations; partial terminations; assignments; 
cancellations; option exercise; or option expiry. 
These proposals move the workflow back to the trader in 
state 104. The trader in turn may update the deal to 
5 reflect the proposal, in which case the workflow 
proceeds from state 104 as described above (i.e, to 
states 102 , 105 or 106), or the trader may reject the 
proposal back to the back office, state 107. 

In addition, the small circles represent 

10 points (l)-{8) at which external publication may occur 
be the printing of "drop copies," described in more 
detail below. 

In the system of the present invention, each 
state has a group of users responsible for processing 

15 the ticket while it is in that state. When processing 
in a given state has been completed, a user may move 
the ticket onto the desktops of the users responsible 
for processing in the next state, which is called 
herein the "State Transition Process". Each time a 

20 ticket is submitted for authorization or is authorized, 
a dialog box may be displayed. Within this dialog box, 
the user may specify which users, or group of users, 
should be prompted to process the ticket next. The 
dialog box preferably has a default, pre-selected user 
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or group of users who are responsible for processing in 
the next state. However, it is possible to include 
more users to the workflow through this dialog box, but 
the ability to exclude users is preferably restricted. 
5 As a ticket moves from a Deal in Progress 

from user to user through the workflow, it appears in 
the user inbox of the user(s) responsible for 
processing it. The user inbox is preferably 
represented by an on-screen indicator which provides 

10 notification of the number of deals awaiting processing 
by that user or group of users. The user may be 
notified of the arrival of new deals for processing. 
By selecting this indicator with the mouse, a user can 
view a list of unprocessed deals. The time each item 

15 was received in the user inbox may also be displayed. 
The user can drill down directly from the list into the 
deal awaiting processing. 

In addition to routing tickets for workflow 
purposes, system users may also send informational 

20 messages to other system users. When moving tickets 
from one state to another, the same dialog box used to 
move the ticket to the next user in the workflow also 
allows distribution of an FYI Message to other users 
not directly in the workflow. The user receiving the 
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FYI Message can read the message and drill down to the 
ticket attached to it in Read-only Mode. FYI Messages 
may also be sent directly at any point in the system, 
with no deal attachment. The user is preferably 
5 notified of the arrival of new FYI Messages . Each user 
typically has an on-screen indicator that provides 
notification of the number of unread FYI messages in 
the user's queue. By selecting this indicator with the 
mouse, a user can view a list of all messages. The 

10 time each message was received may also be indicated. 
Read items are preferably differentiated from unread 
items, and the user can delete any item. 

Each user can display a dialog box with a 
summary of items in the user inbox and the FYI message 

15 queue. 

Ownership of a Deal in Progress may be handed 
off from user to user before being submitted for trader 
authorization, which is called herein a "Deal in 
Progress Transfer" . A dialog box is preferably 
20 displayed allowing the first user to specify which user 
will own and process the ticket next. While the Deal 
in Progress Transfer appears to be similar to the State 
Transition Process, the movement of a Deal in Progress 
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from the queue of one user to another is a lateral 
transfer with no state change. 

Before an "AAA" Deal in Progress becomes an 
authorized deal, it must be approved by an AAA business 
5 manager. This approval is initially obtained during a 
phone call between the trading desk and the AAA 
business manager. The marketer or trader preparing the 
ticket typically records the name of the person 
granting AAA approval on the Deal in Progress. 

10 A Deal in Progress enters the system workflow 

by being submitted to a trader for authorization. (See 
Fig. 7) This function can be performed by a marketer 
submitting a Deal in Progress to a trader, or by a 
trader submitting a Deal in Progress to another trader. 

15 Upon submission, the state of the Deal in Progress will 
change to Deal Pending Trader Authorization 104, and 
the trader will be prompted to authorize it. 

During Trader Authorization, a Deal Pending 
Trader Authorization becomes an authorized deal for 

20 processing by Middle and Back Office users. In the 
case where there is no marketer in the workflow, a 
trader may authorize a deal directly from the Deal in 
Progress state 102 to the Middle Office Processing 
state 106. Preferably, all required fields are checked 
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for population and all fields are validated. If these 
criteria are met, the Deal in Progress ID is 
relinquished, and a unique, permanent ID is assigned to 
the authorized deal. 
5 A deal requiring AAA authorization must be 

authorized by an AAA business manager before moving to 
the Pending Middle Office Processing state 106 (an 
initial authorization by the AAA business manager was 
previously done while the Deal in Progress is created, 

10 as described above) . The trader authorizing an AAA 

trade is advised that the trade is being submitted for 
AAA authorization, and the state of the deal changes to 
Pending AAA Authorization 105. AAA system users 
subsequently authorize the deal to the Pending Middle 

15 Office Processing state 106. 

Middle office authorization occurs when the 
deal has been captured on all relevant risk management 
and payment systems. (See Fig. 8) The deal then 
enters its final active state, Active Deals in Back 

20 Office 107. 

After trader authorization, users may propose 
changes to a deal by entering Proposed Edit Mode. 
Certain aspects of the on-screen appearance of the 
deal, such as the desktop background color, preferably 
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change to indicate that the deal is in Proposed Edit 
Mode. System fields that are editable in at least one 
state then become editable. An optional free-format 
comment field may also be made available to users to 
5 capture an explanation of the proposed edit. 

Once proposed edits have been attached, a 
deal is typically re-submitted for trader authorization 
in state 104. Usually, the trader who initially 
authorized the deal becomes responsible for accepting 

10 or rejecting proposed edits. 

Once submitted, proposed edits preferably 
appear in the user inbox of the trader who originally 
authorized the deal. A proposed edit symbol appears 
next to deals with attached proposed edits to 

15 differentiate them from other Deals Pending Trader 

Authorization. The trader can select the item with the 
mouse and view a summary of proposed edits, which 
include both the original and proposed values of the 
fields being edited. The user proposing the edit, the 

20 time the edit was proposed, and the comment explaining 
the edit may also be displayed. 

A trader may apply or reject all proposed 
edits, or selectively apply or reject edits to specific 
fields. If at least one proposed edit is applied, the 
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amended ticket is sent through the workflow. If all of 
the proposed edits are rejected, the ticket is not re- 
sent through the workflow. In either case, the user 
who submitted the proposed edit is typically advised of 
5 which edits were applied or rejected. 

The cancellation process works like the 
proposed edit process, except that it is a separate 
menu item, and that users propose cancellation of the 
deal in its entirety, rather than modification of 

10 selected fields. A cancellation ticket is sent through 
the workflow. 

Terminations and assignments are processed 
very similarly to proposed edits in system. The 
process may be initiated and authorized at the trader 

15 level, or initiated downstream and submitted for trader 
authorization. In cases of termination or assignment, 
the user is typically prompted for termination or 
assignment fee information, legal effective date, and 
economic effective date. 

20 For full termination, the termination ticket 

is sent through the workflow. For partial termination, 
the user is preferably prompted for the terminated 
notional amount. The original ticket with amended 
notional amount is then sent through the workflow. For 



